-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove --check-cfg
checking of command line --cfg
args
#117522
Conversation
This comment has been minimized.
This comment has been minimized.
3f48f02
to
21109fb
Compare
I don't think this a right thing to do. Why should a specific lint in rustc compensate for deficiencies in cargo (no I think it's fine for people using such a large hammer as |
I personally see this as a short/medium term workaround until Cargo fixes the problem on their end.
Member of the Cargo team have expressed their discomfort and even objection to this.
I agree that from the point of view of rustc it's not great. One possibility could be to make the lint warn-by-default and have Cargo always pass (for now) |
Could you elaborate why we need this short term workaround when the feature is still in nightly? |
The feature is currently in nightly but I want to stabilize it in the near future and as far as I know this issue with To be more precise separating in two different lints lets us have warnings for every unexpected cfgs in the code and in the cli, but with the possibility to individually disable one or another without disturbing the other one. |
See also the discussion on Zulip: https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/check-cfg.20and.20RUSTFLAGS.20interaction |
We (I and members of the Cargo team) had some discussion yesterday about One proposed solution that was suggested by @epage would be to never check This would still mean that we would lint on unexpected cfgs found in the source code no matter the @petrochenkov what do you think about this? |
It is still in the environment, but the rust flags can also be set from the [target.<triple>]
rustflags = ["…", "…"] and those are not included in the So I don't think that a viable option; that's also ignoring that we would have to parse the @rustbot ready |
Then suppressing the warning for all |
21109fb
to
a5658e6
Compare
--check-cfg
use a different lint for CLI --cfg
checking--check-cfg
checking of command line --cfg
args
Could not assign reviewer from: |
@bors r+ |
Rollup of 6 pull requests Successful merges: - rust-lang#116085 (rustdoc-search: add support for traits and associated types) - rust-lang#117522 (Remove `--check-cfg` checking of command line `--cfg` args) - rust-lang#118029 (Expand Miri's BorTag GC to a Provenance GC) - rust-lang#118035 (Fix early param lifetimes in generic_const_exprs) - rust-lang#118083 (Remove i686-apple-darwin cross-testing) - rust-lang#118091 (Remove now deprecated target x86_64-sun-solaris.) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#117522 - Urgau:check-cfg-cli-own-lint, r=petrochenkov Remove `--check-cfg` checking of command line `--cfg` args Back in rust-lang#100574 we added to the `unexpected_cfgs` lint the checking of `--cfg` CLI arguments and emitted unexpected names and values for them. The implementation works as expected, but it's usability in particular when using it in combination with Cargo+`RUSTFLAGS` as people who set `RUSTFLAGS=--cfg=tokio_unstable` (or whatever) have `unexpected_cfgs` warnings on all of their crates is debatable. ~~To fix this issue this PR proposes that we split the CLI argument checking into it's own separate allow-by-default lint: `unexpected_cli_cfgs`.~~ ~~This has the advantage of letting people who want CLI warnings have them (although not by default anymore), while still linting on every unexpected cfg name and values in the code.~~ After some discussion with the Cargo team ([Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/check-cfg.20and.20RUSTFLAGS.20interaction)) and member of the compiler team (see below), I propose that we follow the suggestion from `@epage:` never check `--cfg` arguments, but still reserve us the possibility to do it later. We would still lint on unexpected cfgs found in the source code no matter the `--cfg` args passed. This mean reverting rust-lang#100574 but NOT rust-lang#99519. r? `@petrochenkov`
Back in #100574 we added to the
unexpected_cfgs
lint the checking of--cfg
CLI arguments and emitted unexpected names and values for them.The implementation works as expected, but it's usability in particular when using it in combination with Cargo+
RUSTFLAGS
as people who setRUSTFLAGS=--cfg=tokio_unstable
(or whatever) haveunexpected_cfgs
warnings on all of their crates is debatable.To fix this issue this PR proposes that we split the CLI argument checking into it's own separate allow-by-default lint:unexpected_cli_cfgs
.This has the advantage of letting people who want CLI warnings have them (although not by default anymore), while still linting on every unexpected cfg name and values in the code.After some discussion with the Cargo team (Zulip thread) and member of the compiler team (see below), I propose that we follow the suggestion from @epage: never check
--cfg
arguments, but still reserve us the possibility to do it later.We would still lint on unexpected cfgs found in the source code no matter the
--cfg
args passed. This mean reverting #100574 but NOT #99519.r? @petrochenkov